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REMARKS 

The foregoing Amendment and the following Remarks are submitted in 
response to the Office Action issued on December 1 9, 2005 in connection with the above- 
identified patent application, and are being filed within the three-month shortened statutory 
period set for a response by the Office Action. 

Claims 1-6, 8-14, and 16 remain pending in the present application. Claims 1 
and 9 have been amended to include an additional recitation of subject matter in an attempt to 
distinguish over the cited prior art. Applicants respectfully submit that no new matter has 
been added to the application by the Amendment. In particular, the additionally recited 
subject matter is disclosed at least in the Background section of the patent application as 
filed. 

Applicants again request reconsideration and withdrawal of the rejection of the 
claims consistent with the following remarks. 

The Examiner has now rejected the claims under 35 USC § 103 as being 
obvious over Bruck et al. (U.S. Patent No. 6,801,949) in view of Brendel et al. (U.S. Patent 
No. 5,774,660) . Applicants respectfully traverse the § 103 rejection of such claims. 

Independent claim 1 of the present application as amended recites a method of 

connecting a client application at a computing device by way of a network access module 

(NAM) at the computing device to a server 'server' on a cluster 'cluster 5 having a plurality of 

servers instantiated thereon, where the server is remote from the computing device. In the 

method, the NAM at the computing device receives 'cluster' and 'server' from the client 

application, sends a first request message to 'cluster' requesting first connection information 

for connecting to 'server', receives from 'cluster' a first reply message containing the 
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requested first connection information, and connects the client application to * server' on 
'cluster' based on the received first connection information, wherein once connected, the 
client application and 'server' may transact business. 

Thereafter, and significantly, the NAM at the computing device determines 
that the connection to 'server' has failed, and that the cluster 'cluster' has automatically 
switched processing for 'server' from a first server corresponding to the received connection 
information to a second server when the first server failed, but that the cluster did not provide 
any fail-over support to the NAM at the computing device to re-direct a request from the 
client from the failed first server to the working second server. That is, the cluster has no 
front-end or the like that can itself re-direct such a request, so the NAM at the computing 
device must itself discover how to connect to the second server. 

Thus, the NAM at the computing device and without such fail-over support 
must itself send a second request message from the computing device to 'cluster' requesting 
second connection information for connecting to 'server' at the second server. Thereafter, 
the NAM at the computing device receives from 'cluster' a second reply message containing 
the requested second connection information, and connects the client application to 'server' 
on 'cluster' based on the received second connection information, wherein once again 
connected, the client application and 'server' may again transact business. 

Claim 1 also recites that the method further comprises the NAM at the 
computing device caching the received second connection information in a cache at the 
computing device, and subsequently again receiving 'cluster' and 'server' from the client 
application. Thereafter, the NAM at the computing device retrieves the cached connection 
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information from the cache at the computing device and connects the client application to 
'server' on 'cluster' based on the retrieved cached connection information. 

Independent claim 9 recites subject matter similar to that recited in claim 1, 
albeit in the form of a computer-readable medium with computer-executable instructions 
thereon implementing the method. 

As was previously pointed out, server availability in a clustered system is 
oftentimes increased by allowing the clustered system to automatically switch processing for 
an instance of a server from a failed server to a working server. Thus, the working server 
takes the place of the failed server and restores database services to a client formerly 
accessing data from the failed server. A set of clients and clustered servers interconnected by 
a System Area Network (SAN) is an example of a clustered system that automatically 
switches processing from a failed server to a working server . A SAN is typically operated at 
high speed and is employed in situations where such high speed is required, such as in back- 
office-type scenarios. Such SAN may be accessed by a client by way of protocols built 
according to a high-speed architecture such as the Virtual Interface Architecture (VIA). 
However, the operating system of the SAN does not provide any support to enable VIA 
connectivity to clustered servers thereon, and does not provide any fail-over support to re- 
direct a request from the client from the failed server to the working server . 

Accordingly, and as set forth in the specification of the present application, a 
client application 10 at a client 12 can connect over a network 13 to any one of multiple 
instantiated servers 14 on a SAN 16 by knowing (1) the name of the cluster 18 upon which 
the server 14 resides, and (2) the name of the instance of the server 14 that is to be connected 
to. In particular, the client application 10 provides such information to a network access 
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module (NAM) 20 on the client 12, and the NAM 20 employs such information to obtain 
mapping information from the SAN 16 that provides a physical network end-point for the 
instance of the server 14 on the cluster. 

Thus, the present invention is characterized (1) by the NAM at the client 
resolving such mapping information, as opposed to some entity at the cluster, (2) by the 
cluster not having any fail-over support to re-direct a request from a failed server to a 
working server, and also (3) by the NAM at the client employing a cache at the client to 
cache connection information. Because of (2), then, the NAM must itself perform functions 
(1) and (3) at the client. Notably, the absence of fail-over support at the cluster is a 
detriment. However, such detriment is more than made up for by the fact that the cluster 
need not provide front-end support in this regard and accordingly such cluster can operate at 
a higher speed and can respond to requests faster. 

As was previously pointed out, the Brack reference discloses a load balancing 
server system with a front-end server layer between a network (such as the Internet) and 
multiple back-end servers. The front layer machines comprise a server cluster that performs 
fail-over and dynamic load balancing for both server layers. The operation of the servers on 
both layers is monitored, and when a server failure at either layer is detected, the system 
automatically shifts network traffic from the failed machine to one or more operational 
machines, reconfiguring front-layer servers as needed without interrupting operation of the 
server system. 

Accordingly, a request from a Brack client to a Brack server need only 
address the cluster of such server, and the front-end server appropriately directs such request 
to the correct server, even if such server has moved. Of course, and as should be appreciated, 
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the Brack reference in teaching such front-end server and functionality actually teaches away 
from the present invention as recited in the claims for the reason that such Brack front-end 
server prevents the Brack cluster from operating at a higher speed, with the result being that 
the Brack cluster cannot respond to a request from a client as quickly. 

In direct contrast to the present invention, then, and as was previously pointed 
out, the Brack cluster is disclosed as performing mapping services for a client at a front end, 
and does not in fact disclose a NAM at the client that performs such mapping services, as is 
required by the claims of the present application. Put simply, then, the Brack reference does 
not disclose or even suggest any NAM at a computing device that ascertains connection 
information for connecting to a server at a cluster by performing the actions recited in claims 
1 and 9. Instead, in the Brack reference, such actions would be performed by the Brack 
cluster itself, thus obviating the need for a NAM at the client in the manner recited in claims 
1 and 9. Again, the present invention is for situations where the cluster cannot itself perform 
such actions, such as for example a cluster system with a SAN operating according to the 
VIA architecture. 

The Examiner again notes that the Brack reference discloses a network 
interface card (NIC) at the computing device, and asserts that such NIC may be interpreted to 
be the recited NAM in that such NIC 'basically assists' (sic) in connecting a client to a server 
and performs the functions recited. Applicants respectfully disagree. 

Firstly, and again, Applicants respectfully submit that it is undeniable that the 
NIC at the Brack computing device is not itself in fact disclosed as performing the functions 
recited, as may be shown by reference to the Brack reference at column 17, line 62 - column 
18, line 7. More significantly, a NIC does not in fact 'basically assist' in connecting a client 
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to a server. Instead, a NIC effectuates a connection between the computing device of the 
client and a network to which the server is presumably coupled. As is abundantly known, the 
NIC in establishing the connection does so without any regard whatsoever for whatever client 
on the computing device may be accessing whatever server by way of the network. 

To state that such NIC 'basically assists 5 in connecting the client to the server, 
then, is a gross overstatement. After all, the network also effectuates the connection between 
the client and the server, as does whatever communications cable connects the NIC and the 
network, and as does a user at the computing device that performed some action to initiate the 
connection. However, and critically, neither such network nor such communications cable 
not such user can reasonably be said to be the recited NAM because such items 'basically 
assist' in connecting the client to the server. Put simply, neither the NIC nor any other item 
can reasonably be interpreted to be the NAM at the computing device of the present invention 
unless such item performs the recited functions associated with the NAM at the computing 
device . Quite simply, the Bruck reference discloses no such item at the computing device of 
the client that indeed performs such recited functions of the NAM at the computing device. 
Accordingly, Applicants again respectfully submit in this regard that the NIC of the Bruck 
reference cannot be interpreted to be the NAM of the computing device as recited in claims 1 
and 9. c 

Secondly, Applicants again submit that the inquiry under section 102 is not 
whether such NIC 'basically assists' in performing the recited functions, but whether such 
NIC does in fact perform such recited functions . Inasmuch as the NIC does not in fact 
perform such recited functions, it is immaterial under section 102 whether the NIC assists any 
other entity in performing such functions, especially in that the rejected claims require that 

Page 14 of 17 



DOCKET NO.: MSFT-0688/1 80597.1 PATENT 

Application No.: 09/924,731 

Office Action Dated: December 19, 2006 

the NAM perform such functions at the computing device and not elsewhere. To conclude 
then, Applicants again assert that the NIC disclosed in the Bruck reference cannot be 
interpreted to be the recited NAM of the claims of the present application because such NIC 
does not perform the functions of the NAM at the computing device, as is required by such 
claims. 

The Examiner concedes that although the Bruck reference discloses use of a 
cache, such cache is not at the computing device and is not used by a NAM at the computing 
device in the manner recited in the claims. Nevertheless, the Examiner argues that the 
Brendel reference discloses such a cache. In particular, the Brendel reference discloses that a 
computing device with a browser operating thereon can cache EP addresses (Column 4, lines 
5-16). However, and significantly, such Brendel cache is not used by a NAM at the 
computing device in the manner recited in the claims. In particular, such Brendel cache is 
employed such that a bad IP address is flushed therefrom in an expeditious manner so that 
other browsers do not employ the bad IP address from the cache. 

Thus, Applicants respectfully submit that the Brendel cache cannot be 
interpreted to be the recited cache of the claims of the present application because such cache 
is not employed in the manner recited in such claims. In particular, such cache is not 
employed by a NAM at the computing device to cache 'cluster' and 'server' connection 
information to respond to future requests for such connection information from a client at the 
computing device, as is required by such claims. Moreover, and at any rate, the Brendel 
reference like the Bruck reference fails to disclose or even suggest the NAM at the computing 
device in the manner recited in claims 1 and 9. 
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As a result, and for all of the aforementioned reasons, Applicants respectfully 
submit that the Brack reference and the Brendel reference do not disclose or suggest the 
subject matter recited in independent claims 1 or 9 or any claims depending therefrom, 
including claims 2-6, 8, 10-14, and 16. Accordingly, and for all the aforementioned reasons, 
Applicants respectfully submit that the Brack reference and the Brendel reference cannot be 
applied to make obvious such claims. Thus, Applicants respectfully request reconsideration 
and withdrawal of the § 103 rejection. 
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In view of the foregoing discussion, Applicants respectfully submit that the 



present application, including claims 1-6, 8-14, and 16, is in condition for allowance, and 
such action is respectfully requested. 



Woodcock Washburn LLP 
One Liberty Place - 46th Floor 
Philadelphia PA 19103 
Telephone: (215) 568-3100 
Facsimile: (215)568-3439 



Respectfully submitted, 



Date: March 13, 2006 




Weven H. Meyer 
Registration No. 37,189 
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